IT change management: Real-life examples of normal changes

A structured approach to effectively roll out a major change

Now, let's step onto our second half of our webinar, which is how to build a structured approach to effectively roll out a major change. So, organizations often undertake major changes to perform significant improvements to their products and services, but a lot of planning needs to go into it because you need to bring the right stakeholders on board and ensure that you're prepared for all types of contingencies. And also, your end users should be acceptable to the change. For if not, the change might end up harming the organization more than achieving the intended benefits. So we will see that, how you can implement a successful change with a real-life scenario.

Case study: How do you roll out a change effectively and help your company embrace change?

So we have this SMB here who decide to move their on-prem infrastructure to the cloud for the obvious advantages of speed, reliability, and security.

So this is what they have initially.

They have their Active Directory, their ADFS, a lot of applications, data, and exchange mail servers stored on-premise. And this is what they aim to achieve. They decide to transition to an Azure Active Directory, and they also decide to make use of Office 365 with their SaaS applications. But as you can see, this is a very large undertaking because it involves moving multiple applications and a lot of people and data. But unfortunately, most organizations, when it comes to implementing such major changes, adopt this approach,

"Close your eyes and hope for the best." So what organizations do is that they just go in blind without any sort of planning for different contingencies with a just do it attitude.

Now, that might make a fancy slogan for Nike, but that's totally not going to cut it if you're aiming for a successful implementation because if you do so, all things just fall apart.

Starting with you'd have to end up handling different types of changes with the same change process because one-size-fits-all approach does not help you in this case and creates unexpected setback such as unplanned outages and a lack of resources. And since these outages have not been predicted beforehand, a failure to communicate them creates opposition among your end-users, and a lack of approval mechanism just adds on to the delay in the change lifecycle.

And again, I've been stressing on how planning is crucial to a successful implementation, right? And in case of a failure in the change implementation, and let's say that you don't have a rollback plan, it leads to loss of data and complete chaos. So, all these different roadblocks create poor visibility and an inability to track the change implementation to its successful closure. You started this major change just to improve your services, and you created a catastrophe.

The SMB embraces change with ServiceDesk Plus

But fortunately for this SMB, they have embraced this change with ServiceDesk Plus, and that allowed them to step off in the right direction by following this best practice workflow.

So they started off by defining the various types of changes that they were going to handle. So, they created different types of changes, built change workflows on top of them, and defined those workflows by breaking them down into six custom stages.

So once they have broken it down into smaller pieces, it becomes really easy because they create detailed impact rollout plans, they communicate the downtime effectively to their end-users, and they carry the implementation real carefully. And finally, they undertake a post-implementation review and perform continual service improvements by analyzing change metrics. Now, that might seem a lot, but let's see how simple it is to implement in a service desk tool.

So, again, we are back to the technician's portal, and let me go to quick actions over here, click on Change, and create a new change ticket. So what you're seeing right now is a similar web form to what we saw with service requests but minor differences. So you have this mini calendar on your left-hand side, which shows you the number of changes which are being scheduled. As you can see, no other changes are scheduled, which helps you to avoid change collisions. And as you can see, certain fields which are different over here are your change types.

So, I again said about how this SMB has defined different types of changes, right? So all of them are carried over here such as documented, emergency, major, normal, standard, and they've also created different workflows to handle these different types of changes. And over here, we have change request or the change owner. We have the scheduled start, services affected, and a reason for change.

Scrolling down, we see that there's something known as roles. So what are these roles? Change roles in ServiceDesk Plus helps you to set access permissions for different stakeholders involved in your change implementation. For example, the implementer over here would be able to access the change request, modify it only during the implementation phase. So this helps you to set silos within which your stakeholders will operate, ensuring that no unauthorized activities take place on your change ticket. So once we fill all of these different fields, we will create this change request.

So, I've shown you how a change request is actually created. Let me go ahead and show you quickly how a change workflow looks like. So here we have our change workflow. Let me click on the emergency workflow. So, as you can see, we have different change stages broken down into six stages, and based on the actions performed on the change ticket within these stages, certain transitions would take place.

For example, if the change ticket is accepted in the submission stage, it would move to the implementation phase. That is because this is an emergency change. And in that process, you will be able to notify specific change roles such as change approver and your change manager. So these workflows ensure that you create distinct unique workflows for each different type of changes.

Now, let's go back to our best practice workflow. So as you can see, we had the SMB create different change types, different change roles, different change workflows. They brought all these building blocks together with a change template. Now, all that is left is to break down the change process into six stages and perform the detailed impact rollout plans. Let me take you to the actual change ticket created by this SMB.

So, here we go. As you can see, this is how a change ticket would reflect once it has been created. So as you can see, we have six different stages starting with submission and ending with close. So in the submission stage, the change requester would provide a solid reason for the change, and he or she could go ahead and create attachments and also bring out a detailed reason. Scrolling down, we see some change details and the roles associated with this change ticket. So, once the submission stage has been completely filled up, the change approver would assent this request. Once that has been done, the change ticket moves to the planning stage.

So this is where a detailed impact assessment is taken up, your rollout plans are defined, and your backward plans are defined. So, in the impact stage, the detailed impact on different critical services are displayed over here. The rollout plan in detail describes the implementation. And in case of any unforeseen circumstances leading to a failure in the change implementation, you have your backward plan.

The implementation checklist helps the change team to ensure that they don't lose track of any essential things that are required for the change. And all this planning gives you some insight on what services will go down, and you can create appropriate downtimes. So once you create those downtimes, you will also communicate it to your end-users from within this change ticket. So we click on actions at the top, and we can choose to make an announcement from within the change ticket and also send notifications to specific stakeholders.

Now, once the planning has been done in detail, the change ticket is put through an approval process. So, in the approval stage, your change advisory board comes together, and you can add different change advisory boards and different members of the CAB and ensure that they sit together and review the planning. Once they sit together and perform the planning, they are really happy with this the planning, and they go ahead and approve the change ticket. Once they do that, they change ticket proceeds to the implementation stage.

So as you can see, in the implementation stage, we have projects, tasks and workloads, and downtime scheduling. So why projects? If this had been a minor change, we would just be done with defining tasks and recording the workloads. But this is, as we saw before, a very large undertaking, which involves a large number of tasks and different technicians. So what we do is we create projects to efficiently track the progress of the implementation. For that, we define different milestones and associated tasks to these different milestones. As you can see, this is a lot of tasks. So, you can't effectively handle them from within the change ticket. So you use the tight integration with the project management module.

So you can bring all the different members. That's a really large list as you can see. So you can bring all of these members together in the project. The Gantt chart helps you to track the implementation of the tasks, the milestones effectively. So you can have a bird's-eye view on what is happening with respect to your change implementation. So this really eases the process of change implementation and ensures that it proceeds seamlessly and concludes successfully.

So let us quickly go back to our best practice workflow and see how far we have arrived.

So as you can see, we created a detailed plan, we communicated the predicted downtimes to end-users, and we implemented the change using a project. Now, all that is left is to carry out a post-implementation review to ensure that this change was performed successfully. So for that, we go to the review stage.

So in the review stage, we will add our commands pertaining to the review, and we take care of any patchwork that needs to be done for this particular change. So once the change has been implemented, it proceeds to its successful closure. So as you can see, there were absolutely no risk involved, or let me rephrase it, we ensured that all the risks were preempted using the right capability. So that is how easy it is to make improvements to your services by using a proper ITSM tool. Now, all that is left is to analyze change matrix to enforce continual service improvement.

Is the change process effective?

So, these are the essential metric that we believe you should measure such as number of incidents caused by your change, percentage of unplanned outages, and percentage of bagged out changes. So, this will help you to provide a picture as to how well your change management strategy is coping up and whether it is successful or not.